Expose a native polling method for both authorization and order contexts - #10

Thanks, this is a good idea so worth pursing a little more. The way we currently use this library is from a higher level consumer which has retries but building it into the library consistently would be good.

Things it needs:

• A configurable preferred retry delay and max retry count, instead of waiting 3 seconds and passing in a specific number of retries. This is becomes some CAs are much slower than others, sometimes taking several minutes to complete. Ideally this would be fed into the order context and used where appropriate in the request pipeline.
• Where possible if the ACME server responds with a retry-after header (already used in some places) we should try to honour that, unless the retry-after is not specified or exceeds our max wait time (retry count * retry delay, or something we configure on the order context)

I thought about your second point. However, to implement this we must change the retryCount to a retryTimeout (say, two minutes) so that ACME server doesn't hang the process by giving a retry in an unexpected range (e.g. 1 day). Using retryCount * retryDelay doesn't account for latency of the request itself. Is that acceptable to you as this would be a behavior change to the Generate/Download methods?

Yes, an overall retry/operation timeout would be easier for users to understand as well. Internally we probably care about how often we retry, but users don't.

Due to it being a public API (which, FYI, was changed in post 3.3.3 to have a different default of 3 retries) this is now a breaking change. I tried to make a backward-compatible implementation, but it isn't exactly going to follow the 3 retry logic. Some examples (theoretically):

1. If the server doesn't give Retry-After, it might take 2.5 seconds for first 2 requests (latency+wait) and then wait just 1 second for the 3rd request so it respects the 6 second timeout
2. If the server replies to retry in 1 second, and it isn't ready then and again says retry in 1 second, the 6 seconds will result in ~6 retries.
3. If the server replies to retry in 5 seconds, it will only do 2 retries before timing out. If the server replies to retry in 10 seconds, it will retry once after ~6 seconds ignoring the server's request.

I guess if this is merged it should be bumped as v3.4.0

@webprofusion-chrisc what is needed to merge? Are you testing against an actual CA?

Thanks, it's really just waiting for me to find time to properly review it but just looking over the diff there are still several places where a literal value of seconds (3, 15 etc) is specified and we need to make these configurable.

Thanks, it's really just waiting for me to find time to properly review it but just looking over the diff there are still several places where a literal value of seconds (3, 15 etc) is specified and we need to make these configurable.

I believe the hard-coded values were there before. The new explicit methods for waiting are fully configurable, it's specifically if you Download skipping the new wait method or use the deprecated Generate utility method (does anyone use that in practice, or mostly used by testing)